1. Field of the Invention
The invention relates to alerts and, more specifically, to registering or personalizing alert preferences onto thin clients.
2. Introduction
A thin client may be a device owned by a user. Thin clients allow users to receive incoming communications while away from conventional means of communication, e.g., landline telephones and/or computers. In single-device solution, users are able to enforce their alert preferences at the single device using a limited set of preferences (given the finite set of capabilities associated with that device). However, in multi-device solutions there are two key problems: 1. The default preferences established by a user on one device may not be applicable to a second device because of a disparity in capabilities (e.g., a visual pop-up alert on one device cannot be replicated on another device that lacks a display). Thus, transferring existing user preferences from one device to the next may be difficult; 2. Requiring the user to manually establish preferences on each device used may not be viable (poor user experience due to input constraints, increased error due to manual entry), particularly if the user needs to change default settings based not on the current device used, but on the current context of operation (e.g., in meeting vs. at desk).
In the Galaxy Family of devices, the user has a Smart Module (SM) modem device and typically two or more Thin Client (TC) devices. At a given time, the user may have a single active Thin Client or multiple active Thin Clients depending on their function (e.g. one may have display and another audio). In the course of a day, the user may switch among different Thin Clients depending on where they are at and what they are doing or any other personal preference. They may have one Thin Client for work with corresponding suitable functions and appearance for the business environment. But they may have different Thin Clients for personal use, working out, a night out, etc., each with varying capabilities.
For example, the devices may have different alert capabilities. Alert capabilities include vibrators, display (“silent mode”), flashing lights, polyphonic ringtones, and video ringtones. Thin Clients may only include a subset of these functions. If the user selects the flashing lights indicator to provide an unobtrusive alerting on their business TC, there is a problem as to which alert to use on their “working out” Thin Client when that becomes the active TC.
It is also cumbersome in a multi-device system to change the alert setting on each active device when temporarily or permanently desiring a new setting. For example, when the user wants an unobtrusive setting for all active Galaxy devices during a meeting, they can manually set their SM to vibrator mode, TC1 to display “silent mode”, TC2 to vibrator mode, and TC3 to flashing lights mode. That requires many steps, which will need to be repeated after the meeting to change all devices to the next desired mode.
It will also be necessary to select the settings on a Thin Client with limited UI by using another device. That results in the problem of the user trying to select an alert option that is unavailable on the Thin Client. For example, they user may try to select “vibrator” when only display “silent mode” and polyphonic ringtones are valid options.
For the reasons stated above, and for other reasons stated below which would become apparent to those skilled in the art upon reading and understanding the present specification, there is a need in the art to select preferences that impact multiple devices with minimal user interaction. Further, there is a need in the art for a user to personalized alert preferences using custom menus.